Stop Using Static Security to Protect Dynamic Clouds

Software-as-a-Service (SaaS) hat die Welt erobert, weil es einfach ist. Mit nur wenigen Klicks können Geschäftseinheiten eine Anwendung finden, die für einen bestimmten Geschäftsprozess geeignet ist. Sie können es abonnieren und sofort verwenden – ohne dass die IT-Abteilung davon jemals erfährt.

Cloud Access Security Broker (CASB) entstanden ursprünglich, um Sicherheitsteams bei der Verfolgung und Verwaltung ihres aufkommenden Schatten-IT-Problems zu unterstützen, um ein gewisses Maß an Transparenz und Kontrolle zu erlangen. Doch heute, im Jahr 2021, haben einer Untersuchung von Digital Ocean zufolge 86 % der Unternehmen ihre Abhängigkeit von Cloud-Diensten erhöht. Untersuchungen von Netskope zeigen, dass Unternehmen mittlerweile durchschnittlich 805 verschiedene Cloud-Anwendungen pro Monat nutzen, von denen 97 % unkontrolliert sind. Die wenigen regierten Länder werden wahrscheinlich nicht sehr gut kontrolliert. Ein gewisser Trost für uns ist vielleicht die Tatsache, dass die wichtigsten Unternehmensdaten normalerweise in einigen wenigen strategisch wichtigen SaaS-Anwendungen (z. B. Office 365, Salesforce, GitHub, Google Workspace usw.) konzentriert sind. Dadurch müssen wir weniger raten, was Tausende anderer, weniger bekannter SaaS-Anwendungen betrifft. 

Allerdings landen viele unternehmenskritische Daten auch in benutzerdefinierten Anwendungen, die Benutzer schreiben und in einer Infrastructure-as-a-Service (IaaS)-Cloud wie Microsoft Azure, Amazon Web Services (AWS) oder Google Cloud Platform (GCP) bereitstellen. Diese Umgebungen unterscheiden sich ausreichend von der lokalen Welt. Die Tools, die zur Überprüfung der Integrität von Anwendungen und Infrastrukturen verwendet werden, die vor Ort erstellt wurden, sind für die Cloud nicht besonders gut geeignet. Bei der Entwicklung aller lokalen Sicherheits- und Überwachungstools wurde von einer statischen Existenz ausgegangen. Die Infrastruktur war festgelegt und die Anwendungen und Daten waren statisch. Die Cloud kehrt diese Denkweise um und ist dynamisch. Die Dynamik in der öffentlichen Cloud führt dazu, dass viele herkömmliche Sicherheitstools nicht mehr funktionieren. 

Multi-Cloud stellt internes Fachwissen vor Herausforderungen

Fast jede Organisation auf dem Planeten nutzt mittlerweile eine Multi-Cloud. Viele werden für einige Projekte AWS verwenden, für andere GCP und für wieder andere Azure. Im Falle von Fusionen und Übernahmen kann die Wahl einer Cloud-Plattform sogar zwangsläufig erforderlich sein. Manchmal kann die Entscheidung für eine bestimmte Plattform gegenüber einer anderen auch eine Frage der Eignung für eine bestimmte Anwendung oder der Kenntnisse des Entwicklers sein.

Eine der Herausforderungen besteht darin, dass es schwierig genug ist, auch nur auf einer dieser Plattformen Experte zu sein. Jeder Dienst kann über Hunderte verschiedener Dienste verfügen und die Kommunikation der Dienste untereinander erfolgt auf unterschiedliche Weise. Beispielsweise unterscheidet sich das Zugriffskontrollmodell für AWS von allen Zugriffskontrollmodellen, die Sie bisher für andere Dienste gesehen haben. Daher ist es schwierig genug, ein AWS-Experte zu sein. Wie können Sie möglicherweise auch ein Experte für Azure und GCP sein? Es ist ein Kampf. Das menschliche Gehirn kann so viel auf einmal einfach nicht verarbeiten. Dennoch ist es nicht wert, gegen Multi-Cloud zu argumentieren. Jedes Unternehmen nutzt mittlerweile eine Multi-Cloud. 

Richten Sie Ihre Teams auf Cloud-native Sicherheit aus

Die meisten betriebsbereiten Cloud-Dienste (ob IaaS, PaaS oder SaaS) bieten eine Reihe nützlicher integrierter Sicherheitskontrollen, die zum Schutz vor gängigen Bedrohungen ausreichen. Beginnen Sie mit diesen Schritten, wenn Sie ermitteln möchten, welche Schritte zur sicheren Verwendung eines Cloud-Dienstes erforderlich sind. Wahrscheinlich gelangen Sie jedoch an einen Punkt, an dem die integrierten Kontrollen keinen ausreichenden Schutz vor neuen Bedrohungen bieten. Sie könnten zu dem Schluss kommen, dass den integrierten Funktionen die Flexibilität fehlt, um detaillierte Richtlinien auszudrücken. Möglicherweise stellen Sie auch fest, dass Sie Arbeiten wiederholen, z. B. das Konfigurieren einiger DLP-Regeln in Microsoft 365 und im Wesentlichen ähnlicher Regeln in Amazon Macie. Wer möchte sich schon die langweilige Aufgabe antun, die Konsistenz von Dutzenden Steuerelementen in Hunderten von Anwendungen manuell zu überprüfen? Der Ausweg aus diesem Dilemma besteht in der Einbindung cloudnativer Sicherheitskontrollen eines Drittanbieters für Cloud-Sicherheit. Ich werde einige Beispiele nennen.

Einige integrierte Steuerelemente sind unvermeidlich: Sie müssen mit ziemlicher Sicherheit Personen- und Dienstidentitäten (auch als „Sicherheitsprinzipale“ bezeichnet) im integrierten Identitätsverwaltungssystem von IaaS/PaaS/SaaS erstellen. Sie müssen außerdem Zugriffskontrollen für Ressourcen über einen integrierten Ausdrucksmechanismus bereitstellen. Ein Cloud-Sicherheitstool eines Drittanbieters kann die den Sicherheitsprinzipalen gewährten Rechte sowie die für Ressourcen konfigurierten Berechtigungen kontinuierlich überwachen, um sicherzustellen, dass die Rechte nicht zu weit gefasst und die Berechtigungen nicht zu umfangreich sind. Wenn ein einziges Tool die Berechtigungen für Ihren gesamten Cloud-Bestand verwaltet, wird ein Grad an Konsistenz und Vorhersagbarkeit erreicht, der andernfalls praktisch nicht erreichbar wäre.

Ein weiterer Bereich, in dem Cloud-native Sicherheitstools von Drittanbietern brillieren, ist die Identifizierung vertraulicher Informationen und die Kontrolle ihrer Verbreitung. Ich habe zuvor die mühselige Arbeit erwähnt, die mit der Konfiguration und Pflege doppelter DLP-Regeln verbunden ist. Inkonsistente und unvollständige Regeln bergen echte Risiken und schaffen potenzielle Angriffsziele. Aber wissen Sie: Den meisten SaaS-Anwendungen fehlt jegliche Form von integriertem DLP. Ich wette, dass zumindest ein Teil der vertraulichen Informationen Ihres Unternehmens in einer Handvoll DLP-freier SaaS-Anwendungen gespeichert ist. Eine Cloud-native DLP-Funktion – etwas, das jedes gute CASB bietet – eliminiert doppelte Arbeit und gewährleistet die Konsistenz der Richtlinienaktionen in allen Ihren Cloud-Anwendungen und -Projekten. Anders als im vorherigen Beispiel, wo das Drittanbietertool ein integriertes Steuerelement erweitert, ersetzt das Drittanbietertool hier ein integriertes Steuerelement oder aktiviert ein solches Steuerelement, wo kein integriertes vorhanden ist.

Es gibt keinen einheitlichen Markt für „Cloud-Sicherheit“. Stattdessen buhlen Hunderte von Produkten auf etwa einem Dutzend, sich teilweise überschneidender Märkte um Ihre Aufmerksamkeit. In fast allen Fällen haben Startups Sicherheitslücken in der Cloud erkannt und mit überzeugenden Angeboten reagiert. Im Laufe der Zeit haben die großen etablierten Sicherheitsanbieter viele solcher Startups übernommen. Der Grad der Integration kann sehr unterschiedlich sein: Eine Plattform, deren Funktionen Ressourcen und Konfigurationen gemeinsam nutzen, übertrifft ein Portfolio aus zufälligen Dingen. Um mehr über neue und aufstrebende Märkte zu erfahren, lesen Sie die Berichte Ihrer bevorzugten Branchenanalysten. Sprechen Sie mit Ihren Kollegen, die möglicherweise bereits Erfahrungen mit Anbietern auf diesen Märkten haben. Bevorzugen Sie Anbieter, die integrierte Plattformen anbieten und mit bestimmten Teilen Ihrer vorhandenen Infrastruktur arbeiten können, etwa Ihrem Verzeichnisdienst, Ihrem SIEM und Ihrer Endpunktschutzplattform. Führen Sie einen Proof-of-Concept durch, um die Eignung für den Verwendungszweck zu überprüfen.

Ihre Daten, Anwendungen und Personen sind schon lange nicht mehr statisch. Auch Ihre Sicherheit sollte nicht statisch bleiben. Der beste Weg, die Cloud zu schützen, ist durch die Cloud selbst – das war schon immer so und wird auch immer so sein.

Artikel ursprünglich veröffentlicht beim Forbes Tech Council.